Software Vault: The Games Collection 1/software vault.zip/software vault/CDR10/YICN23.ZIP/DOC/FAQ.DOC

Text File | 1993-03-06 | 14KB | 389 lines

Some questions and a few answers on YakIcons concepts:



What is Xmode?

Xmode is a tweaked mode of the VGA display card that displays the screen in
planar form instead of a single array of memory.  It was "discovered" and
discussed in Mike Abrash's column in Dr. Dobb's journal, and has become
the focus of much discussion, particularly among game programmers.  See Dr.
Dobb's journal issues 178-179.  X mode allows planar addressing of the VGA,
allowing processing of pixels in parallel, increasing puts from memory to
screen almost fourfold.  It also allows multiple pages in video memory,
making double-buffering much easier.


Okay.  What the heck is double-buffering?

Double-buffering is a technique where one page is written to in "hidden"
(off-screen) memory and then the display card is told to look at that memory
(make it visible).  This allows all of the changes to a screen to be displayed
at once, without the user being able to see the changes individually.  While
the new page is being shown, the old one is written to, and the pages flip
back and forth.


I thought that was just called "page-flipping."

It was.  The technique has been around a bit (I first saw it on an apple II+,
and it was around before then, I'm sure), and for the most part was used to
animate graphics on machines where the screen was exactly the size of the
screen memory.  Now, though, video display cards can address memory that is
much larger than the screen size, and with different display modes, video
memory can have different-sized "pages" depending on mode, size of virtual
screen, etc.  So instead of calling the blocks "pages," people refer to them
as "buffers"-- just amorphous hunks of memory the card can address.  If enough
memory is available, triple, quadruple, or higher buffering is possible.


What's the point?  People can only use one page at a time.

Agreed; for most animation concepts, two pages is plenty.  Uses for a third
page in video memory include a movable split screen (for scores, etc),  storage
in video memory of sprites...


What's a sprite?

A sprite is an object that is put on the graphics screen.  People tend to use
the term for most any object on the screen, but really the term "sprite"
refers to an object that doesn't disturb the background.


Wait.  If you put it in video memory, it HAS to disturb the background.

True, to a point, but there are sometimes hardware alternatives which can
display a background page and then "layer" hardware sprites over it.  Most
arcade games do this.  Also, you can use that third page in memory for a
static background page that can be copied onto where the sprite was, thus
effectively "erasing" it.


So why not use standard memory?  It's cheap nowadays.

It's cheap, but it's not fast for this.  The reason?  The video display card
can only look at video ram.  To transfer the data from standard memory
to video memory, the computer has to go through the interface with the card.
16-bit interfaces are pretty standard, and that's slow compared to the
32-bit motherboards we have today and also slow compared to the quick memory
transfers on board most display cards.


Why not keep all image data in the display card?

There's not enough room.


Why don't vga manufacturers put more memory on their cards?

Video ram costs more, and not everyone uses their PC for games.


Why not?

No idea.


How come even though I'm a great programmer, my graphics look terrible?

Lack of artistic talent, probably.  Mine look pretty bad too.  It's tough to
make pixels look like anything good unless you're a skilled computer artist.


A friend of mine tried to help me out; he draws fantastically, but he can't
do a thing with the computer.  What can he do to get better?

Well, there are some tricks to computer art, especially art in a restricted
mode like 320*200 which has fairly large pixels.  Most people underestimate
the power of a single dot.  One misplaced pixel can make a small sprite look
terrible.  EVERY dot is important, and unless you're willing to hunker down
and decide what each dot should do, it'll look stiff, square, and cartoonish.


Good enough.  But now everything's blocky.

Ah, the joy of dithering!  With 256 colors, there's no reason at all that
color fades can't be smooth and elegant.  This can be used to our advantage;
in the Psygnosis game Blood Money, there were quite a few stalactites that
seemed very pointy, even though they stayed the same width (one pixel) most
of their length.  The reason?  The color faded slowly from white to dark blue,
and the effect was that the stalactite got thinner.  This can be used on
curved surfaces, where the "stairstep" effect can be very detrimental.  If,
for example, you have a circle

     **
    ****
    ****
     **

Looks pretty blocky, right?  Now take a darker shade of that color and fill
in the corners.

    .**.
    ****
    ****
    .**.

Here, it looks even more square.  On the graphics screen, though, this makes
the circle look a good deal more circular, because our eyes see the dithered
corners as more rounded edges.  Make sure you use the most full range of colors
that you possibly can!


Um... looks good on a black screen, but now my sprites vanish when I put them
on my background.

Encase everything in a thin layer of black.  This can also help to eliminate
blockiness.  Suppose you have a square:

   **
   **

Outline it in black, but don't fill in the corners...

   ..
  .**.
  .**.
   ..

Looks much better, and shows up on backgrounds!  Look at Ultima 7 for a good
example of outlining.  You may also want to take up miniature painting; a
good deal of the tactics are similar.



Nice so far.  But the actual workings of YakIcons are a little beyond me.

You're probably trying to read more into it than you need to.  Implementation
of Yakicons is not that tough.  The best thing to do is get into the sample
programs.  Play with them.  Tweak them.  They're yours, after all!


What's so great about an animslave?  Why can't we just have animicons?

Animslaves POINT at animicons, so they work just as well without taking up
all the space.  Of course, you have to have one copy of the real icon for
the animslaves to look at.


Won't all the animslaves be in sync then?

No, not necessarily.  An animslave can advance (look at a different frame of
the animicon) without the original icon or any other slave knowing about it.
It's quite possible to have many animslaves all showing different frames
while slaving off the same icon.  Best of all, they don't take much memory
at all!


Do they mind being slaves?

No.


Why the static variables like iconTable, eventTable, ficonTable, and
feventTable?

Static variables are accessible from all members of the class.  These tables
are used to hold the icons that the actors slave off of.


Why not have just one big table for all the classes to slave off of?

So you can separate them all.  This way, you can load all the events (spells,
explosions, whatever) into event_table and all your regular actors (tanks,
priests, whatever) into icon_table.  Or the faced-versions of both.


Why does animactor have a turn function that does nothing?

It needed to be included in the virtual function call table for animactor,
because when factors spawn something, they "turn()" it to the same direction
they're facing.  But I wanted factors to be able to spawn animactors, so
I had to include the turn() function in animactor too.


What's spawning good for?

Good question.  Usually, you'll use actors for the "usual" animations of
someone or something.  But if your boodlino slashes a grumjug, you don't
want to show the boodle doing his usual thing, you want him to slash with his
sword.  However, removing the boodlino and replacing him with a different actor
(the slasher) is clumsy.  So spawn the slashing-boodle event, and he'll be
drawn doing that instead.  It's easy once you figure it out.


What are events good for?

Events are unique in that they remove themselves once they're done playing.
This allows us to put explosions, fires, whatever on a map and forget about
them, since they clean up after themselves.


So if I spawn an event, the program will go back to drawing the original
actor after the event is over?

Yep.


How do scripts work?

Well, that's a little iffy.  They're not well developed yet, but they're doing
okay.  Basically, once you add a line to an actor, it starts going, executing
each line and deleting it as it goes along.  It's best to move actors using
script lines; they take care of themselves pretty well.


Okay, this is pretty much the same as it was during your last release.
what's new?

Almost everything.  Be more specific!


Why the new format change, causing your programmers to have to search and
replace half their function names?

I didn't like the underscores, and was starting to program in a different
style (the "mixed case").  To avoid mixing styles, I reformatted everything.
It won't happen again-- promise!


What's a yakLib?

It's an archive format similar to a .zip or .arj.  I needed a way to put all
the data a program could need into one file.  DId you notice all the millions
of ".drw" files were gone?


Actually, I had.  I LIKED the .drw files; they were smaller than .yaks.  Why
did you change?

Ease of use, mostly.  I wanted a file format more compatible with x mode, so
I didn't have to convert every time I loaded.  The .yaks do compress a lot
more, though, when crunched with a zip'er or arj'er.  Hadn't you noticed?


I keep getting undefined errors in linking.  What's up?

Make sure you're in the large memory module and are inlcuding every .obj
file you need!  This can be hairy.  look at the example projects.


This gadget thing is really losing me.

Keep trying.  Look at the demo programs--I can't explain them any better.
The best way to learn this stuff is just by doing it.


When I use page flipping, the mouse vanishes just like it does in animap.exe.
What gives?

The page flipping is confusing your poor little rodent.  You'll have to
physically draw the mouse cursor on every page if you want it there.




I'm still lost.

Look at the examples.


What if I'm still lost after that?

write me.  I'm serious.  I WILL get back to you or address your problem in
an issue of the mooYaks newsletter.


The WHAT?

The mooYaks newsletter.  I'll be putting it out periodically after I have
a list of people to send it to.  So give me your address.  It's free!


What are YOU doing with yakIcons?

That's not as important as what YOU are doing, but if you must know, I have
three major projects on-line:
Morningstar: Cybergenic mechanized combat.  Better than Battletech!
Coverdale: Roleplaying in a rich fantasy world.  Should be GREAT.
Shadow of the Beet: I'm not really oriented to action games, but I want to
                    see if I can write one.



What's upcoming in future releases of YakIcons?

Well, a rewrite of the icons class is in order so it can handle different
types of files than ".yak" and ".drw" files.  Windows .BMP's and .GIF's are a
possibility. There are also a few more animaps I need to design.
Hex maps would be pretty easy, but my next big project is an isomap, like the
displays on Populous or Four Crystals of the Trazere.
I'd also like the maps to save the actors within them! (also shouldn't be
too terribly hard if each actor knows how to save itself).
FM instruments for the Soundblaster coming soon, along with music!  Also, the
zooming routines will allow for differential zooming-- ie viewing icons at
an angle.  You can see the yakMaze 3-d scrolling object coming, can't you?


Why "Yak"?

Gnu was already taken.


That's a joke, right?

Not really; GNU C is a great public-domain compiler, and I thought: hey, if
they can do that, I can sure as heck put out a free game programming library.


Can I modify YakIcons?

As long as you don't distribute it afterwards, sure.  If you come up with
something really cool, let me know!  I will be VERY busy in the coming year,
and while I expect yakIcons to be updated, I expect the updates to originate
from you, the users.  I NEED speed; I've tried a few different methods to
make animaps faster, but so far it's been inconclusive.  If you have any
ideas, let me know!



Can I use YakIcons in my own programs?

If I didn't want people to use it, I wouldn't have distributed it!


Wait a sec.  Is there a catch?

No, not really.  Use YakIcons all you want.  I got really tired of people
requesting $60 or $80 for graphics packages when most shareware games don't
make all that much.  However: if you do break dollar one, it'd be a real
treat if you'd lob a share my way.  Whatever percentage of your product you
think YakIcons helped with, send that percentage of your first $1000.
(ie if you make $10 off one nice guy the whole time, just give me $2).  You
don't have to do this at all-- YakIcons IS shareware, but it's free-- but it'd
make me a lot more inclined to give out future releases without registration.
Give me what you think I deserve.  20% seems about right, I guess, since
everyone I've talked to about shareware games has gotten about $100 total,
and YakIcons does make development a lot faster (Boodles took me a week of
spare time, including graphics drawing, without considering fine-tuning Yak)
Twenty bucks isn't much... especially if you make $80 out of the deal.
And I don't think it's fair that I should make anything if you don't.  If
you're not getting bread for your game, don't send me any.  But I would
appreciate if you'd

1) Put some sort of notification in your program that you used YakIcons
2) Let me know that you've made something with it!

Above all, have fun and good gaming to ya.  Any questions, drop me a line.
Until 13 Dec 1993, I should be at:

Victor B. Putz
2102 W. Loop 289 #191
Lubbock, TX 79407-1775

Or send it to my parents; they'll have my current permanent address:
YakWare c/o Victor B. Putz, Sr.
701 Bellevue Blvd. South
Bellevue, NE 68005